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Principles of 00 design, Part 2 



Alan Knight 


L ast month, we reviewed some important principles of 
00 design, many of which apply equally well to life. 
■The fundamental principle of 00 is: A/ever do any 
work that you can get someone else to do for you. And there 
are secondary pri nci pies: 

•Avoid responsibility 
• Postpone decisions 

This month we examine a few more principles. 

MANAGERS DON'T DO ANY REAL WORK 

The subject of "manager" or"control" objects can provoke 
a lot of debate in 00 circles, much as the subject of "man¬ 
agers" does in other work environments. Some argue that 
the role of manager is inherently bad for software design 
and thatoneshould avoid employing them. Others argue 
that, although many of them represent a throwback to 
outdated ways of thinking, they can be very useful under 
the right ci rcumstances. 

I definitely believe that managers can be useful, but it's 
important to distinguish between good ones and bad 
ones. For example, consider a program in which most of 
my classes are "record objects" (objects whose only be¬ 
haviours areget and set methods). The real work is done by 
a control class that manipulates these objects with full 
access to all their data. At this point I have a procedural 
program dressed up in an 00 disguise. The control object 
is in the most complete possible violation of the funda¬ 
mental pri nci pie because its tryi ng to do al I the work itself. 

On the other hand, consider a window class like the 
VisualWorks Application Model or the Visual Smalltalk Appli- 
cationCoordinator. These are manager objects that coor¬ 
dinate the interactions between user interface widgets 
and the domain model. They’re very important to good 
GUI design and it would be much harder to get a clean 
design without them. 

People who are vehemently opposed to any kind of 
manager object are often stuck in the trap of tryingto pre¬ 
cisely model the world, taking the 00 paradigm much too 
literally. One of my favourite quotes on thissubject (from 
several years back) is from Jeff Alger, who wrote: 

"The real world is the problem; why would you want to 
just simulate it?" 
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How can we tell a good manager object from a bad 
one? We apply the principle that managers don't do real 
work. A manager object should manage interactions be¬ 
tween other objects and should betryi ng to do work itself, 
unless it's legitimate management work. 

An example of legitimate management work is an Ap- 
plicationModel figuring out which menu items need to bedis- 
abled. An example of nonlegitimate work would be doing 
(nontrivial) calculationsof values to bedisplayed in its fields 
Those values should be calculated by the domain objects. 

This rule can be tricky to apply i n practice. It is always 
obvious whether something is legitimate management 
work or not. Always remember that this is just a specific 
exampleofthefundamental principle. Ifthe manager can 
plausibly get someone else to do the work, it should do so. 

Another difficulty is that the word "M anager" is some- 
times tacked on to the end of a class name even though 
what it describes is not a manager at all. In a recent 
comp.object discussion, Robert Cowham (cowhamr@logi- 
ca.com) described a DiscountPolicyManager object and 
worried about the desirability of introducing a manager 
object even though itseemed to make the design cleaner. 
The description was as follows: 

A Discount Policy Manager is going to be passed, say, an 
Invoice object and will calculate the appropriate dis¬ 
count to be applied to that I nvoice (using methods on 
the Invoice to find out about it) and then use a method 
on I nvoice to add the discount to it. 

Reading this description, it's clear that the Discount 
PolicyManager is reallyjust a policy object as described in 
the previous section. It isn’t a manager at all and should 
be called DiscountPolicy instead. 

PREMATURE OPTIMIZATION LEAVES EVERYONE 
UNSATISFIED 

The most fun you can have as a programmer is optimizing 
code. There’s nothi ng quite so satisfyi ng as taki ng some I it- 
tlepiece of functionality and making it run 50 ti mes faster 
than it used to. When you’re deep in the middle of mean¬ 
ingless chores like commenting, testing, and document¬ 
ing, the temptation to let go and optimize is almost irre¬ 
sistible. You know ifegotto be done sometime and you feel 
like you just can't put it off any longer. Sometimes you’re 
right and the time has come to make this piece of code 
really scream. More often than not, continued on page23 
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the object. Actuator is also a candidate for use whenever 
special initialization actions must betaken once the iden¬ 
tities of an object’s attributes or collaborators are known. 

Solution: Create a setting accessor method for the attri¬ 
bute. Move dependent initialization code into the acces¬ 
sor immediately after the value is set. Ensure that the 
object itself, when created, uses this accessor for initializ¬ 
ing the attribute and that clients use it for changing the 
attri bute’s value during the I ifeti me of the object. 

Implementation: Movecodefrom initialization and other 
methods into a new accessor method. (If the object was 
initially designed for the given attribute to be constant, 
some research may be required to find all the initializa¬ 
tion code that is dependent on the attribute.) Note that in 
some cases (e.g„ when event handlers have been estab¬ 
lished on a collaborator), it may also be necessary to write 
code in the accessor to perform finalization actions 
before the collaborator can be replaced. 

Consequences: Application of this pattern maybe benefi¬ 
cial even when attributes aren’t expected to change at 
runtime because it associates dependent initialization 
logic more closely with the attri bute it appl ies to. Actuator 
can reduce the size of complex initialize methods by mov¬ 
ing their logic into separate accessors. 

Related Patterns: Application of this pattern is similar to 
Template Method in that itturnsan initialize method with 
much attri bute-specific logic into askeleton thatdelegates 
to a series of lower-level accessor methods. However, 
unlike Template Method, those lower-level methods are 
concrete and not usually intended for overriding. 

Actuator is also related to Observer in that dependent 
code runs in response to some change in state. However, 
Observer is intended for loose coupling between two or 
more objects at runti me, whereas Actuator is for setti ng up 
at development time, quick responses to changes within a 
single object. 

COMING UP 

The next arti cl e of my th ree- part seri es consi ders two fam- 
i I ies of patterns: validation patterns for checking and pro¬ 
tecting domain objects and informational patterns for 
managing status and validation messages. The third and fi¬ 
nal article will review afamily of optimization patterns, ffl 
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you'll be happier in the long run if you can just hold off a 
little longer. 

There are several reasons for this. First, time spent on 
optimization isn’t being spent on those "meaningless" 
chores that are often more important to the success of the 
project. If testing and documentation are inadequate, 
most people won't notice or care how fast a particular list 
box updates. They'll have given up on the program before 
they ever got to that wi ndow. 

That’s not the worst of it. Premature optimization is 
usually in direct violation of the principle of postponing 
decisions Optimization often involves thoughts like "if 
we restrict those to be integers in the range from 3 to 87, 
then we can make this a ByteArray and replace these dic¬ 
tionaries lookups with array accesses”. The problem is 
that we’ve probably made our code less clear and we’ve 
greatly reduced its flexibility. It may have felt really good 
at the time but the other people involved in the project 
may not be entirely satisfied. 

Of course this rule doesn’t apply to all optimizations. 
Most programs will need some optimization sometime 
and this is particularly true in Smalltalk. As a very high- 
level language, Smalltalk makes it very easy to write very 
inefficient programs very quickly A little bit of well- 
placed optimization can make the code enormously 
faster without harmi ng the program. 

There’s also a large class of optimizations that I call 
"stupidity removal” that can be profitably done at just 
about anytime. These include things like using the right 
kind of collection for the job and avoiding duplicated 
work. Their most important characteristic is that they 
should also result in improvements to the clarity and ele¬ 
gance of the code. Using better algorithms (as long as 
thei r details don't show through the layers of abstraction) 
can also fall into this category. 

OTHER RULES TO LIVE BY 

There are many other rules of life that can be extended to 
the00 design and programming domains. Here are a few 
more examples. Feel free to make up more and send them 
to me. M ake posters out of them and putthemuponyour 
office wall. It'll make a nice counterpoint to those insipid 
posters about "Teamwork" and "Quality” that seem to be 
everywhere these days. 

•Try not to care—Beginning Smalltalk programmers 
often have trouble because they think they need to 
understand all the details of how something works 
before they can use it. This means it takes quite a whi le 
before they can masterTranscript show: ‘Hello World'. 

One of the great leapsin 00 isto be ableto answer the 
question "How does this work?” with "I don't care”. 

•Just do it!—An excellent slogan for projects that are 
suffering from analysis paralysis, the inability to do 
anything but generate reports and diagrams for what 
they’re eventual ly goi ng to do. continued on page32 
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G ETTIN G REAL continued from page 19 

name first clusterl nBucket: empCIuster. 
name middle clusterl nBucket: empCIuster. 
name last clusterl nBucket: empCIuster. 

" cluster the address and its components" 
address :=anEmp address, 
address clusterl nBucket: addressCluster. 
address street clusterl nBucket: addressCluster. 
address city clusterl nBucket: addressCluster. 
address state clusterl nBucket: addressCluster. 
address zip clusterl nBucket: addressCluster. ]. 

Thiscolumn has described how to determine if clustering 
objects might help application performance and how to 
cluster objects using ClusterBuckets. My next column will 
discuss how to measure overall system performance and 
steps for tuning multi-user Smalltalk for higher transac¬ 
tion throughput. K 
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•Avoid commitment—This is another way of 
expressi ng the princi pie of postponi ng decisions but 
one that might strikeachord with younger or 
unmarried programmers. 

• It’s not a good example if it doesn’t work—This one 
comes from David Buck (dbuck@magmacom.com), 
who’s fed up with looking at example and test 
methods that haven’t been properly maintained as the 
codeevolved. I can'tthinkof a wayto applythisto life 
but it's good advice anyway. 

• Steal everything you can from your parents—A 
princi pie for those tryi ng to make effective use of 
inheritance or movi ng i nto their fi rst apartment. 

• Cover your a**—Like in a bureaucracy, the most 

i mportant thi ng i s to make su re that it i sn't your fault. 
M ake sure your code won’t have a problem even if 
thi ngs are goi ng very wrong elsewhere. SI 


SEQUENTIAL KEY ALLOCATION 

continued from page26 

ifTrue: [ keyCache : = self nextKeys: self 
keyCacheSize ]. 

key : = keyCache first. 
keyCache removeFirst. 

"key. 

If you choose to make the array optimization in the 
nextKeys: method, this method must be changed to insert 
nil values into the array as each key gets returned rather 
than using the removeFirst selector, ffl 
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